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GENERAL CESCRIPILON 


The 81000 data communications subsystem provides an interface 
between the network controller and any executing MCS on the 
system. The character-’oriented header information which the MCS 
reads or writes in its communication with the network controtler» 


the remcte files in its own network» and the MCP basically 
constitutes the MCS interface that is described in this product 
specification. The MCS interface is composed of the various 


messages rsquired for any queries or changes in the status of 
remote stations. 


The siniaua requirements for this datacoga environment are an NOL 
handler and a user program which opens a remote file with headers 
Can MCS). There is no restriction on the number of remote files 
with headers that may be opened on the system» although there is 
a maximum of 20 remote files that can be concurrently associated 
with any one station. In a system composed of several MCSs» a 
Station may be associated with more than one of thee in a hier-~ 
archical manner. 


In general» the network controller handles the tine protocol and 
the MCS» in cooperation with the network controtters, handles the 
attachment of remote std&étions to their respective remote files. 
Remote file I/O» standard to the 81000 systems is controlled by 
the operating system through a queue file sechanism that is 
transparent to the user and therefore not discussed in this 
document. 


An MCS program wiil fuifill some or atl of the following data 
cogaunicattons neeas: 


- Message switching 


- Logical attachment of a station to a remote application 
program or systere of prograas 


- Network reconfiguration 
- Audit and recovery 
- Network statistical analysis 


- Communication with the operating system. 


REMOTE £ILES 


Remote files are the means by which programs use the NDL datacoam 
subsystem tc transfer information from resote terminals to user 
programs Cor vice yersa). MCS-type remote files are distin= 
guished fros ordinary remote files only by the special headers 
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that allow them to affect the flow of messages. 


MCS interface is enabled by opening a remote file with headers 
that has an external file name which matches a file declared in 
the file section of the executing network controtter. Act 
stations Listed in the family statement for that file are 
controited by the MCS. The SQ-byte header that precedes data 
messages aitows the MCS to access tallies» toggies and other 
information relevant to the station originating the message. 
Non-data messages consist only of the variable-Length header. 


Dummy remote filese i»ze.» with no stations specified» are allowed 
as long as the program opening the dumay remote file (Cwithout 
headers) has been zip~executed by an MCS-type progran. The MCS 
is expected to direct the assignment of stations to that fite by 
approving or disapproving the open of any remote station that 
wishes to be attached to that file. 


RESOURCE SHARING 


Where muttiple MCSs are executing on the sage system» there is an 
established protocol which allows one MCS to attach stations to 
another. The protocol is based upon the concepts of “primary” 
and “secondary™ and these teras refer to the relative respansi- 
bilities of two MCSs in the control of a reasote station. 


Since users may sign on or attach to a series of MCS-type files» 
primary files (Cwith some restrictions noted below) are distin- 
guished from secondary files onty by signat characters: and by 
their relative positions in the master list of attachments kept 
for each station in the remote network. The primary file is the 
last remote file oan the master List to which the station is 
attached and the secondary file is the nextctortlast. By default» 
all interface messages go to the primary files ands if the first 
character of the message matches the signal character defined for 
the secondary file Calt secondary files must have a signal char- 
acter)» the message goes to the secondary file. The advantage of 
this configuration is that a remote station can still communicate 
with the secondary file even though it has a prigmary attachment 
to another remote file. 


Secondary files are restricted to remote files opened with 
headers since they must have signal characters associated with 
thea» and primary files may be either ordinary remote files or 
remote files opened with headers. In a series of remote attach- 
ments done by an individual station» there is a Limit. of one 
attachment to a remote file without headers: it must be the 
pri@ary file. Tf atl of the attachments are to MCS-type remote 
files» there is a Limit of 20 attachments for one remote station. 
Primary and secondary protocol is maintained through a master 
List that is updated by the network controtler each time a resote 
station attaches or detaches itself froa an MCS or a remote file. 
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When a station signs on or attaches to a remote file» the file- 
name is added ta the List and @ signal character is associated 
With it if it is an MCS. If a third attach/sign on is made» the 
primary and secondary designations are reconfigured. After 
redefinition» the original MCS does not have any current respon- 
sibilities where the remote station is concerned and is inacces~ 
sible frem that station. 


Hhen a reacte station is detached or closed» the Last entry is 
deleted from the List and primary and secondary are reconfigured 
from the master list. In this way» the originait MCS Cin a series 
of three attaches) is saintained on the List and the _ final 
close/detach must be from the first (Coriginat) MCS. MCSs 
designed to inhibit the primary-secondary option do so by denying 
aft opens on reaate files with headers. 


BASIE TERMINOLOGY 


This subsection defines most of the basic terminology that is 
used in this product specification. It also references related 
publications that would be helpful to those who are unfaasiliar 
wath those terms and concepts. 


MCS Message Controti System °- Any pfogras 
which opens a remote file with the 
header option and thereby controls the 
stations in that remote file. 


NC Network Controller = The program gener- 
ated through compilation of an NDL 
(Network Definition Language) progran. 
The NC handles the line discipline for 
the data communication devices of a 
system and interface queue between MCS 
and operating system. Refer to P.5. 
2212 52235 81000 NOL and 1073715>5 NOL 
Reference Manual. 


Remote File A file dectared in a program which» in 
conjunction with the network controtlier, 
provides input» output or 1/0 with a set 
of data communication devices. Refer to 
PS. 2212 5462, B1000 MCPII and 
1089992» Data Communications Information 
Manual. 


Headers An option on a resote file which allows 
system control functions and provides a 
.0-byte header on all data messages 
moving through- that reasote file. 
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Primary File 


Secondary File 


Controliing Remote File 


Attach Initiator 


User Program CU.P.) 


LSN 


RSN 
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The file to which a station was most. 
recently attached or included tin an 
open. Normal input goes to the prigary 
file. 


The file to which a station was just 
previously attached or included in an 
open» itw».@e» the penultimate attachment. 
The secondary file sust have headers and 
wilt have approved the attach or open of 
the primary fite. | $Input whose first 


Character matches the signal character 


(not blank) designated in the prisary 
file's attach or open will go to the 
secondary file. 


CCRF) is the file with headers to which 
a station was most recentiy assigneds 
either with an attach or with an opene 
If the primary file has headers» it is 
the CRFs otherwise» the secondary file 
is the CRF. 


is the file which writes an attach. 


normally denotes a program which has 
opened or is oapening a remote file 
without headers. 


Logicat Station Number - The number by 
which the network controttler uniquely 
identifies a station for normal transac- 
tions. LSN*s begin with “001” and 
proceed sequentially through ail the 
stations declared in the Station section 
of the NOL controtter. 


Relative Station Nursber ~- The number by 
which a user program with a resote file 
using a remote key uniquely identifies a 
station. An RSN equal to 0 iaplies a 
control message. An RSN equal to 1 
implies the first station in the file's 
family statement. RSN*s proceed sequen- 
tially through the stations detineated 
by a file*s family statement» except 


that a controtling resmote file may 
modify the LSN.LIST and thereby modify 
the RSN"s of the remote file. If a 


Station 18 detached from a file with a 
remote key» the RSN*s remain unchanged. 
If a station is attached to a file with 
aremote keys the new RSN will be its 


BURROUGHS CORPORATION 
COMPUTER SYSTEMS GROUP 
SANTA BARBARA PLANT 


RELATED DOCUMENTATION 
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old RSN if it were attached previously>s 
otherwise» it will be one targer than 
the greatest RSN previously associated 
with the file. 


NAME NUMBER 
B1i000 Network Definition Language P.S. 2212 5223 
61000 NOL/Library P.S. 2212 5215 
B1000 NOL Reference Manual 1073715 
Data Cogaunications Reference Manual =-1089992 


B1000 Data Comm Audit 
B1i1000 MCPII 


Po5S- 2212 5421 
P.Se. 2212 5462 
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MESSAGE TYPES 


This section specifies the record formats of the sessages read 
and written by the MCS 4s it communicates with both the network 
controtler and the remote stations in its remote file. 


There are three types of record formats: data» control and user= 
defined. Data record format is used in the transfer of informa~ 
tion between network controllers and remote stations and in this 
area the MCS may read or write the record» depending on the 
source and destination of the #sessage. Control records are 
defined by name and represent a specific purpose and actions 
@eGes a detach.reply. User-deftned record format is used for 
coma@aunication between an MCS and a. user remote file without 
headers and» as its name indicatese it allows the user program to 
establish the purpose of the cossaunication. 


ALL -messages recognized and written by an MCS are tisted by type 
and foraat. 


Table 2.1 MESSAGES READ 


MESSAGE TYPE, FORMAT 
CUTPUT MESSAGE (from REMOTE FILE) "00" ; DATA 
INPUT MESSAGE (from STATION) "01" DATA 
INPUT LOGICALACK =02" DATA 
GOOD .RESULTS.REPLY "05" DATA 
RECALLED .MESSAGE "06" DATA 
UNPROCESSED.QUTPUT MESSAGE "07" DATA 
OPEN =10" CONTROL 
ATTACH | "12" CONTROL 
ATTACH .REPLY "13" CONTROL 
DETACH "14" CONTROL 
DETACH.REPLY m5" CONTROL 
CLOSE. "16" CONTROL 
STATUS.REPLY "21" CONTROL 
CHANGE.REPLY "23" CONTROL 
RECALL.REPLY "25" CONTROL 
REMOVE .REPLY "27" CONTROL 
REMOTE. FILE. INFO-.REPLY "29" CONTROL 
LINE .RELEASE.REPLY "31" CONTROL 


REMOTE .FILE.INTERCOMMUNICATION =O") =. “99° USER-DEFINED 


ome 
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Table 2.2 MESSAGES WRITTEN 


MESSAGE TYPE FORMAT 
OUTPUT MESSAGE (to STATION) "90" DATA 
INPUT MESSAGE (to REMOTE FILE) "O1" DATA 
LOGICALACK.REPLY "93" DATA 
OUTPUT GOOD.RESULTS "04" DATA 
OPEN.REPLY "11" CONTROL 
ATTACH "12" CONTROL 
ATTACH.REPLY ; #43" CONTROL 
DET ACH "14" CONTROL 
STATUS "20" CONTROL 
CHANGE "22" CONTROL 
RECALL "24" CONTROL 
REMOVE "26" CONTROL 
REMOTE.FILE.INFO "28" CONTROL 
LINE .RELEASE "30" CONTROL 


REMOTE.FILE.INTERCOMMUNICATIOGON 720" ..=: SOO" USER-DEFINED 


Y IQ ABBREVIATION 


In Tables 2.3 through Sel» the following abbreviations and nota- 
tions are used: 


NC = Network controller/operating systes interface 
MCS - Remote file with HEADERS 
USER - Remote file without HEADERS 
R - Read . 
W- Write 
Note: 


"*" under a “W" implies that it ts appropriate for that program 
to SET that field. 

“*#" under an "R"™ implies that it 1s appropriate for that prograa 
to READ that field. . 

"+" under a “W" taplies that it ts mandatory for the MCS to SET 
that field before sending the message. 

"9" japlies a numeric EBCDIC character field (Bit 8) 

"“X" aimsplies an E€CDIC character field (Bit 8) 

"a" denotes iterations of the same fields one for each 
remote station 
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DATA MESSAGES 


The types of data messages which an MCS reads and writes are as 
follows: 


TYPES WRITTEN DESTINATION AND FUNCTION 


00 An cutput message to any station in its 
remote file. 


01 An input sessage to any remote file. The 
destination of the message is indicated by 
the number in the remote.file.no field. 


03 A togicalack.reply message to the network 
controiler. This message should atlow the 
relevant request to acknowledge receipt of 
the message via an ack to the station. 


04 A gdod.results message to the network 
controiler. This message acts like an output 
message except that positive receipt of the 
message by the station produces a good.re- 
sults.reply. 


TYPES READ ORIGIN AND FUNCTION 
00 . An output asaessage from a remote file whose 
apen it approved with participating set to 
“1°, 
O1 An input wessage from one of the following: 


A primary station when the signal char- 
acter is not used. 


A secondary station when the signal char- 
acter designated in the open or attach or 
attach.reply is the first character of 
the message. 


A remote file with headers. 
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02 An input Logicalack message from the network 
controiter. This message is received when a 

request executes a terminate logicalack. If 


the primary has headers» it receives this 
messager otherwisesr if there is a secondary 
file it gets the message. 


05 A good-results-reply wessage from the network 
controller #s received upon successful trans- 
mission of an output message to a station. 


The message is received only if the 
good.resutts bit in the message or station 
was sete If the primary remote file has 
headers» this message is received by the 


prigary files otherwise» the secondary file 
receives it. 


06 A recalled.message frox the network 
. controiter. Recailed.messages follow the 
recall.repiy message. The number of recatled 

messages is indicated in the recatl.reply. 

O7 An unprocessed.output wessage froa the 
network controller. When the network 
controller is DSed» it sends output messages 
to the appropriate controlling remote file 
before sending an EOF. 


The data message format is defined as: 


Table 3.1 DATA RECORD FORMAT 


NC=mNCS MCS-NC MCS=-USER USER=CS FIELD LENGTH 
W R W R W R W R PIC 
MESSAGE. TYPE * * + * + («) (*«) * 99 
VARIANT * * te * * - = 9 
LSN * * * * * («) (*) * 999 
TEXT.SIZE te * + + + (*) (*) t 9(4) 
REMOTE~FILE.ND a * ik * + - - 999 
TIME * * - - 9(7) 
TRAN.NO * * - = 999 
ERROR * o - - XX 
TALLYS * * * * = = 9(9) 
TOGGLES * cy te & = - 9(8) 
TERMINAL.WTYPE i * - - 99 
END_KEY * * X 
FILLER X(5) 
* * * * * * *& & XCTEXT.SIZE) 


TEXT 
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The parenthesized fieids in Tabte 3.1 for user remote fites 
indicate the three fields in the remote key. The remote key has 
the following format: 


RSN 9(3) 
TEXT.SIZE 9(4) 
MESSAGE.TYPE 9¢3) 


RSN is converted to LSN by the remote file interface. 


The semantics of the fields in the header are: 


VARIANT A field indicating the following: 
= 1 ** make program memory resident 
= 2 == make progras disk resident 
‘= 3 «= cause EOF branch 
= 4 == cause exception branch 
= 5 == include text in good.results.reply 

LSN The Logical station nusber to which the 

- data belongs. It must be set on output 
and good.results messages. 

(TEXT.SIZE . The number of characters in the text 
field. 

REMOTE.FILE.NO The nuaber of the remote file where the 

i message came from or is going to. It 
must be set on input messages. 

TIME The tise in 20-bit counter format when 
the network controller processed the 
messages. 

TRAN.NO | The transmission number that belongs to 
the. message. 

ERROR A 16-bit field extracted from the result 


descriptor which indicates exception 
conditions. The meaning of the bits of 
this field are as follows (Cbit O=most 
Significant bit): 


BIT EXCEPTION 

parity error 
buffer over ftow 
read memory parity 
time out 

break 

end of buffer 


Vide WN © 
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TALLY 
TOGGLE 
TERMINAL.TYPE 


END_KEY 


TEXT 
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6 Loss of DSR 

4 toss of carrier 
8 address error 

9 translate error 
10 forsat error 

Li read not ready 

12-15 not used 


The semantics of tatty» toggle and 
terginal.type are the same as in 
previous reteases: the tatty fietd 
represents the first three station 
tallies in 3echaracter deciaal format. 
The toggle field represents the first 
eight station toggles as "70% or "1". 
Terminal.type is the two-digit designa~ 
tion that tdentifies each ctass of 
terminals. 


Valid oonty for ¥CS that deats with 
CO80L74 programs on a SEND. 


"0" if no ending indicator. 

"1" if end of segrent indicator. 
"2" if end of -message indicator. 
"3" if end of group indicator. 


iu ti 


The character string which is ordinarily 
displayed on the remote screen or the 
focal operator display terainal (ODT). 
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CONTROL MESSAGES 


QPEN MESSAGE 


The open message is the mechanism for creating new remote files. 
The -operating system receives an open fror a program and deter- 
mines that the device is arenote file. A remote fite open 
message is then formulated and passed to the network controller 
Which takes the following actians: . 


1. If the file is knowns it modifies the message to indicate 
the apprapriate station tists if unknowns the open is 
disapproved with file sissing. 


2. Verifies that the open message is valid. If note it 
disapproves the open. 


3. If none of the stations in the open are assigned to an 
MCS» it approves the open and creates a new remote file. 


4. If some of the stations in the open are assigned to one 
MCS and the rest are unassigned», it forwards the open 
message to the NCS. 


5. If the stations in the open are assigned to more than one 
MCS and the program attempting the open was not zip- 
executed» it disapproves the open with file Locked. 


6. If the program whose open is being processed was 2zip= 
executed by an MCS» then the list of stations in the open 
is examined. If all the stations in the list belong to a 
different MCS> then the open is forwarded to that 
program. If a discrepancy exists» then the oapen is 
forwarded to the MCS that zipped the prograsr. 


7. If it is a dummy file with headers but was not zip- 
executed by an MCS» the open is approved. 


8. If it is a dummy file without headers and the program was 
not ziptexecuted by an MCS,» it wilt be disapproved. This 
is done because there is no way to attach stations to the 
resote file after the open. 


OPEN REPLY 


If the open is passed ta an MCS» an open.reply is expected. The 
MCS must approve or deny the open. It may» in additions modify a 
nusber of other fields as specified in the diagram on the open 
format Cunder MCS-W). If a denial is sent» no changes will be 
made» the denial will be forwarded to the operating system which 


4n2 


BURROUGHS CORPORATION COMPANY CONFIDENTIAL 
COMPUTER SYSTEMS GROUP MESSAGE CONTROL SYSTEM INTERFACE 
SANTA BARBARA PLANT Pe. Se 2212 S447 CF) 
will deny the open to the opening program. A signat character 


indicated in the open.reply enables the station to communicate 
with the MCS. If openetype is cutput or if participating is set» 
no changes wilt be made to primary or secondary assignments. 


If both participating and headers are set» the open will be 
disappraved by the network controller and a close with open.error 
set will be dispatched to the MCS. 


When the network controller receives an open.reply from an MCS» 
it rechecks all fields relevant to itself and the operating 
system. If the MCS made an error in formulating the replys» the 
approval wilt be changed to denial and a close will be sent to 
the MCS with open.error = "1". Otherwise» the new remote file 
wilt be created and the reply forwarded to the operating system. 


QPEN WITH HEADERS 


An MCS way approve an open with tne headers option set» indi- 
cating another MCS. At this time» the primary file is the file 
whose apen was approved and the secondary file is the file which 
approved that open. ALL messages whose first character is the 
designated signal character go to the secondary file. Alt others 
go to the primary file. Then» if the second MCS approves an open 
with that station or attaches that station to a third resote 
files. the first MCS is teft out» the second MCS becomes the 
secondary file and the new remote file becores the primary file. 


An example of secondary attachment would be a station running 
under the ittustrative MCS which first signs on to a special MCS 
which» in turns retrieves certain types of information from a 
data base on cogsand and then from the second MCS signs onto an 
inventory review prograg. As the user reviews the inventory» he 
way at any tigwe type in his signal character and query his data 
base through the special-purpose MCS. In order to contact’ the 
illustrative MCS» however» he aust first sign off from the inven- 
tory review prograa. ; 
An example of a participating open would be a station running 
under the illustrative MCS signs onto a special MCS which formats 
messages according to terminal type» sets up forms» displays data 
attractively, et Cer and from this second MCS signs onto the 
inventory review program. The second open is approved with 
participating set to "1". In this case» primary messages are 
sent to the special MCS and secondary messages stili go to the 
illustrative MCS. 
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QPEN WITH SIMPLE HEADERS 


A remote file with SIMPLE_HEAQDERS is used as a headers file with 
a few exceptions. 


A 50-byte message header must be prefixed to every message sent 
or received by the program using the file. The anly exception to 
this is that the result of a “TERMINATE ERROR™ done by the WNC 
caused an “"7O0N EXCEPTION" condition to be set for the file» as 
with a sigple remote file» instead of the usual procedure for a 
headers file. 


A SIMPLE_LHEADERS file witt not receive unsolicited responsess 
that is» no OPENs CLOSE,» ATTACH» OETACH>s or LOGICALACK messages 
wiil be queued for the file. 


A SIMPLE_HEADERS file may set TALLIES and TOGGLES in the message 
header» as welk as issue GOOD_RESULTS>» REMOTE_FILE_INFO> and 
STATION_STATUS messages» but may not write ATTACH, DETACH, 
CHANGEs RECALL» LINE_RELEASE or COBOL@4-related messages. CALL 
COBOL74 QUEUES will be SIMPLE_HEADERS files.) 


One sore difference between SIMPLE_HEADERS and fult headers files 
is that in the case where the OPEN for aeremote file with 
SIMPLE_LHEADERS is forwarded to an MCS» the MCS may approve the 
OPEN with “"PARTICIPATING® set. 


DUMMY REMOTE QPEN 


If the MCS approves an open with current stations = O». then the 
open will be approved with no stations initially attached. Each 
message directed to that remote file wiit cause the MCP to deter- 
mine whether the LSN«=>RSN association has -been established 
already in the FI8 and establish it if necessary. The message 
will then be processed as usual. This facility allows a remote 
file to be opened with no stations attached initially and 
messages then to be sent Cunder direction of the approving MC5) 
to the file without the indicated station having been explicitly 
attached by the MCS to the remote file. 


QPEN/OPEN.REPLY EQRMAT 


The forsgats for the open and open.reply sessages are shown below. 
Included are indications of relevant fields and following is an 
explanation of each field*s meaning. 


BURROUGHS CORPORATION 
COMPUTER SYSTEMS GROUP 


SANTA BARBARA PLANT 


Table 


MESSAGE.TYPE 
OPEN .TYPE 

OPEN. TIME 

PARENT .JO8.NO 
PROGRAM. JOB.NO 
PROGRAM.NAME 
HEADER.CPTION 
SIMPLEsHEADER.OPTION 
USE.REMOTE KEY. 
ESIDENT | 

| USERJREMCTE.FILE.NO 
\ SIGNAL .CHAR 
APPROVE.DENY 
DENIAL. REASON 
PARTICIPATING 
GOOD.RESULTS 
MAX.STATIONS 
CURRENT. STATIONS 
LIST.TYPE 
FILENAME 
PROTOCOL .TYPE 
SESSION 
STATION.LIST 
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The semantics of the fields of the open message are as follows: 


OPEN.TYPE 


OPEN.TIME 


PARENT.JOB.NO 


PROGRAMA. JOB.NO 


PROGRAM.NAME 


Indicates the directions of data flow 
aliowed the remote files 


"1" == jnput only 
"2" -= gutput only 
"3" == input/output 


The tiwe at which the MCP recognizes the 
file open. 


The jot nuaber of the program that zip- 
executed the program opening the rerote 
file or 70000000". 


The job number of the pregram opening 
the remote file. 


The name of the proegrar opening the 
remote file. 
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HEADER.OPTION 
SIMPLE .HEADER.OPTION 


USE.REMOTE.KEY 


RESIDENT 


USER REMOTE.FILE.NO 


SIGNAL .CHAR 


APPROVE.DENY 
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A boolean indicating whether the file is 
allocated With MCS-type headers’ and 
functions. 


A boolean which» when set along with 
HEADER.OPTION, indicates to the NC that 
simple headers are to be used. 


A booiean indicating whether the file 
includes the key option. The remote.key 
option ailows writes to specific 
Stations and on reads indicates’ the 
Station which sent the current message. 
For files without headers» stations are 
identified by relative station nuabers 
CRSN*%s). 


A value indicating what to do on a read 
with no data: 


"i" -- keep prograsg in memcry 
"2" -- roll programs out to DISK 
"3" == provide EOF branch 


The tlogicat fite nusber which the 
network controttler uses to identify the 
opening file throughout the remote file 
interface. The MCS must not change this 
field. 


Used by the network controtler to iden- 
tify wessages intended for the MCS froa 
a station. | Blank iaplies no signal 
character. 


Indicates | to the operating system 
whether the open should be approved>s 
"1" japlies open approval. 
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DENT AL.REASON 


DENIAL .REASON: 


a nemhene em ene a2am«a ee 


VES AN ee © 


wan n 


PARTICIPATING 


GOOD.RESULTS 


MAX.STATIONS 


CURRENT.STATIONS 
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Indicates the reason for an open denial. 
The DENIAL.REASON say be set by an MCS 
to any of the following (Csome have _  ~no 
Logical meaning to an MCS): 


MEANINGS MCP REPORTS AS: 
No reason NO REPORT 

File missing FILE.~MISSING 
Fite Locked FILE.LOCKED 
Adapter missing FILE.MISSING 
MCS denies. FILE.LOCKED 

No roca in NC for FILE.LOCKED 
remote file 

Invalid LSN List FILE.MISSING 
Too nested FILE.LOCKED 

MCS missing. NO REPORT 
Invalid station count NO REPORT 

A boolean indicating whether the 
approving MCS witl participate in the 

user program's I/0. It is set by the 


approving MCS and causes all input fron 
the station and atti output from the 
remote file to be sent to the approving 
MCS rather than the user program. No 
changes are made to the primary oar 
secondary files of the stations ina 
remote file open with participating set 
to “1". 


Set by the MCS to indicate that the 
network controtier shouid return 
good.results messages upon successful 
transmission of data messages to the 
station. 


The number of stations that can be 
attached to a given file. It is set by 
the program atteapting to oapen the 
remote file as part of the file declara- 


‘tion. 


The number of stations that are in the 
Station.list to be originally attached 
to the file. Current.stations equal to 
"000" indicates a dummy file. This 
creates a file which only the approving 
MCS Cor any MCS gaining knowledge of its 
reaote file number) may talk to» and 
Which stations could tater be attached 
tO« 
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LIST.TYPE 


FILE .NAME 


PROTOCOL.TYPE 


SESSION 


STATION.LIST 


4-7 


COMPANY CONFIDENTIAL 
MESSAGE CONTROL SYSTEM INTERFACE 
Pe. Se 2212 S447 CF) 


Indicates the method by which the user 
program specified his remote file. The 


-yalues of this field can bes 


"0" -- file name 
"i" == station dist by name 
"2" -= station List by LSN 


Type "O° is the only one currently 
tapterented. 


A fteld providing the file name given by 
the user program. This name must satch 
a fite name deciared tin the file section 
of the NOL prograa which generated the 
controller unless the user prograa was 
executed under control of an MCS. If 
the file name given does not exist and 
the user program is under control of an 
MCS > then the open wilt be passed to 
that MCS. However» the file name is not 
@unique file identifier. The stations 
in a given NOL file may be modified so 
as to be shared by two remote files or 
passed on to another renote file with 
the same name. In future releasess 
fites may also be designated by station 
lists» so reliance on file names to iden=- 
tify remote files is not recommended. 


Indicates the type of remote file inter- 
coagunication desired by the application 
prograg opening the file. 


(See P. Se 2219 0482. SMCS for an 
example.) 


The remote session number associated 
with the application program perforaing 
the open. It is “0000" if there is no 
session association. 


Contains the List of stations (by LSN) 
included in the renote fiile.. Each LSN 
occupies 3 characters in the list (See 
CURRENT.STATIONS above). 
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QPEN REVIEW CRITERTA 


When an 
network 


A. 


D. 


Before 


Ae 


He 


C. 


open is approved without being sent to an “MCS, the 
controller verifies that: 


There is room in the remote file table as indicated by 
the max files stateraent in the NDL dectaration section. 


Current.stations is less than or equal to amaxestationss 
if not» it is set to max.stations. 


The following conditions are true: 


1. the station exists 
and 2. the adapter is present 
and 3. the station is appropriates j.e.» that 
a. the old primary is null 
or b. the old prisgary does not have headers and the 
secondary is null and the open.type is output 


the file is not a dummy file without headers. 


an open is forwarded to an MCSp the network controller 


. .werifies that: 


There is room in the rewote file table as indicated by 
the max files statement in the NOL declaration section. 


Current.stations ts tess than or equal to max.estationss 
if nots it is set to max.stations. 


The remote file being opened» if it is a dummy files was 
zip-executed by a program with headers. 


The foilowing conditions are true: 


1. the station exists 
and 2. the adapter is present 


and 3. the station is appropriates i.e.» that 


ae the primary is null Cnot all stations) 
or b. the primary is the approving MCS 
or c. the priaary does not have headers and the 
secondary is the approving MCS 
and 4. the nesting of open approvals and attaches is 
not too deep. 


old 
cr2") 
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Before an open.ereply is processed and approved for the user 
program» the network controller verifies that: 


Aj The open on this remote file was sent for open approval 
B. The MCS set approve.deny to "1" indicating approval 

C. Current.stations is less than or equal to maxestations 
D. Headers and participating are not both set 

E.~ The fotlowing conditions are true: 


1. the station exists 
and 2. the adapter is present 
and 3. the station is appropriates i.e.» that 
ae the old prisgary is nult : 
or be. the old prirgary is the approving MCS 
or ce. the old prisgary does not have headers and 
the old secandary is the approving MCS | 
and 4. the nesting of OPEN approvats and attaches is 
not too deep 
and 5. if participating» the primary is the approving MCS. 


The following tables suamarize the action that the N.C. wiil 
take when it receives an OPEN or an OPEN.JREPLY. 


BURROUGHS CORPORATION 
COMPUTER SYSTEMS GROUP 


4-10 
COMPANY CONFIDENTIAL 


MESSAGE CONTROL SYSTEM INTERFACE 


SANTA BARBARA PLANT P. Se 2212 S447 CF) 
OPEN 
i ALL 1 SOME OR ALL LSN'S 1 SOME OR | 
1 LSN*S | BELONG TO SAME CRF 1 ALL LSN®S 1 
1 AVAIL (ocr eterececeeeseces= 1 BELONG TO 1 
i {RF = CRF IRF Z= CRF &t OTHER RF 1 
cose nnweceeee | wen eces | sewn nees | om ceremeen | wees ene sane] 
1 ZIPPED QR ji | | ] 1 
§ EXEC BY i A § FCRF 1 DFL i DFL | 
1 NON MCS i t I t { 
aietalatatetatatatetatel Sebstatatatated Retetatatatete wa fomee nen nes |on---- -----1 
! ZIPPED §oFMCS =mMCS!I /= 1 l | 
i 8Y i fore |----] FMCS i FMCS i 
i MCS : PFMCSIFCRE I § ] 
OPEN.REPLY 
j ALL | SOME OR ALL LSN*S BELONG TO 1 
1 LSN*S | A RF ! 
1 AVAIL JPowtoe ene sen ew ccs e wnat ecnenaecan= |] 
i t RF=CRF 1! RF /= CRF 1 RF /= CRF 1 
j i i PRIMARY 1! PRIMARY | 
i i 1 EMPTY { NO i 
I i | i SEC=MCS i 
su auasc seca anwe J emaceaneon maa seane = wm ewaenaaae naeanmasaana ene a I 
FROM NON 1 ] 
KCS I DFL ! 
seme eres eane |] ene en nee amesece conse asaneeseacscos sane | 
FROM i ICRFICRF 1 ! DETACH t 
KCS j A b=! /= 1 A 1 THEN | 
i mMCSEMCS 1 ] A j 
i {-er[----] ! 1 
{ ;aAitc | i I 
LEGEND: 
A = send approve to MCP 
c - send close to MCS and deny open 
CRF - CONTROLLING REMOTE FILES If PRIMARY has HEADERS, 
then PRIMARY» etse SECONDARY 
DFL = denys file tocked 
FCRF =- forward to CRF 


forward to MCS 
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ATTACH MESSAGE 


The attach is a mechanism whereby new Stations are assigned to an 
existing rewote file. Whereas the open message allows an initial 
assignaent of stations to anew remote file» the attach protocol 
adds stations to the file subsequent to the open. 


There are three important remote files (not necessarily unique) 
associated with an attach. 


1. The attach initiator begins the attach process by writing 
an attach message. Eventualty he witl expect to receive 
an attach.reply which wilt either approve or deny the 
attach. The station List may be modified if the attach 
is forwarded to another MCS for approval so it gay be 
necessary to review the station List in processing the 

completed attach. 


2. The attach object is the remote file to which the 
stations are being attached. If the attach object is not 
the attach initiator» the open of the attach object must 
have been approved by the attach initiator. The attach 
object may or may not have headers. In either cases it 
receives no indication of the attach within the attach 
protocol, but may become aware of the attach via the 
inclusion of new stations in its noragal sessage flows via 
a reaoteefilesinfo» or via a user-defined conventions. In 
the case where this internal attach has been attempted» 
and the rerote file for the MCS is full» an ATTACH.REPLY 
with OENY» MCS.FULL will be forwarded to the attach 
initiator. 


3. The controlling remote file (CCRF) of a station is the 
file with headers to which the station was most recently 
attached Cor included in an open). If the primary has 
headers» it is the CRF otherwise» the secondary file is 
the CRF if one exists. 


If the CRF of each station in the station.list is the attach 
initiator or null» the attach is immediately processed and an 
attachereply sent back to the attach initiator. The signat char- 
acter specified in the attach will direct control messages to the 
attaching file for all the stations he controls. 


If the controtiling remote file for the stations in the attach is 
arerote file other than the attach tnitiator,» the attach message 
is forwarded to the CRF and an attach.reply is expected in 
respanse. The CRF gust approve or deny the attach and may modify 
the station List of the attach. He also specifies the signal 
character for all stations he controls. This attachereply is 
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then reviewed Dy the NC» which either approves the entire attach 


and 
as t 
the 


processes it or denies it. In either case» the attach.reply 
hen sent on to the attach initiator. If another MCS approved 
attach but the NC denied it» a detach is also sent to the CRF 


With attach.ereply.in.error set to "1". 


If 


a station is unattached» it may be incluced in an attach. 


However» when the attach is precessed by the NC,» no secondary 
wiil be assigned. 


If. 


the stations in the stationelist have more than one CRF,» the 


attach will be denied by the network controller. 


Follt 
the 


ATTACH TABLE 


owing is a table indicating the status of a station before 
issuance of an attach and after the receipt of an 


attach.reply. Participating or output~only stations are not 
included in the table because stations attached in those two 


classes do not change primary and secondary assignments. 

p = primary file 

S$ = seccndary file 

self -= attach initiator (headers) 

CRF = controlling reaote file (not self) Cheaders) 

user = remote file whose open was approved by self (no headers) 

CURRENT STATUS ATTACH TO SELF ATTACH TO OTHER FILE 
Status if approved status if approved 

unattached 

p=null,» s=null p=self» s=null p=others s=null 
Signai.char ignored Signai.char ignored 


attach.reply from NC attach.reply from NC 


attached to self 


p=self p=self p=others» s=self 


Signal.char ignored attach signal.char 
attach-reply from NC attach.reply from NC 


attached to CRF 


p=CRF p=self» s=CRF p=others s=CRF 


attacherepty Sigechar attach-reply sig.char 
attach.reply from CRF attach.reply from CRF 
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p=usersr s=null 


p=users» s=self 


p=users s=CRF 


attach denied by NC 
P=user, s=null 
attacherepty from NC 


p=users s=self 
Signai.char ignored 
attach.reply froa NC 


p=self» s=CRF 
attach.reply sig.char 
attach.reply from CRF 


Table 4.2 ATTACH 
MCS-NC 
W R 
MESSAGE.TYPE + re 
USER»REMOTE.FILE.NO ee « 
ATTACHING. REMOTE .FILE.NO 
SIGNALSCHAR * * 
APPROVE.DENY 
DENTAL -REASON 
PROGRAM. JO3.NO 
ATTACH. TIME 
CURRENT. STATIONS + * 
ATTACH.CQOUNT 
FILLER 
LSN.LIST ¢ 


MCS = attach initiator 


CRF = cantroiling remote file 


P. S. 2212 5447 CF) 


attach denied by NC 
p=users s=null 
attachereply from NC 


p=other,s s=self 
attach signat.char 
attach.ereply from NC 


p=others s=self 
attach.reoly sig.char 
attachereply from CRF 


NC~-CRF 
R ‘PIC 
* 99 
ote 999 
t 999 
xX 
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9 
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* 9(7) 
* 999 
* 999 
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Table 4.3 ATTACH.REPLY 


MESSAGE.TYPE 
USER.REMOTE FILE .NO 


ATTACHING.REMOTE.FILE.NG 


SIGNAL .CHAR a, 


PPR Deny @ 
SENTRA EASON / 
PROGRAM.JOB.NO 
ATTACH.TIME 
CURRENT.STATIONS 
ATTACH.COUNT 
FILLER 
LSN.LIST 


The semantics of the 


ATTACHING. REMOTE.FILE.NO 


SIGNAL.CHAR 


CRF-NO NC=-MCS 
WoO W R PIC {3 
+ * * * 99 
* * 999 
* ® * 999 
te * * xX 
a * ® tt 9 
# * 9 
* * 9(7) 
* Cd 9(7) 
* * * 9993 
* 999 
X¥€3) 
* ® C999)#4 
fieids in the attach and attach.reply 
@essages are sisilar to the open with the following exceptions: 
The file number of the MCS originating 
the attach or attach-.reply. It is set 
by the network controlter before 
forwarding the message to another MCS. 

_ Set by the controtling remote file. It 
is used by the network controller to 
identify messages intended for the 
secondary file of a station. Blank 


DENTAL.REASON 


PROGRAM.JOB8.NO 


implies no signal character. 
ously 
whose CRF is attaching to hiaself>» 


For previ- 
stations and stations 
the 


unattached 


Signal character is ignored. 


Set 


by 


following va 


eee 


wie 
now 
hed « Tab 


«7° 


ball ¢ Toad 


On 


( 


th work controller when an 
attach ns eueET It may have the 


| 


~ MCS full 

- invalid remote file 
file tocked 

adaptér issing 

CRF denied the attach 
Cnot used) 

invalid LSN in list 


= too many MCS*s for one of the stations 


(the nesting of the apens and attaches 
ts too deep) 

- attach.ereply error 

“= too many stations in file 

attach 


an is the job number of the 
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ATTACH.CNT 
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owner of the attaching remote file. On 
an attach.reply this will be the jobd 
number of the controlling remote file. 
If this field corresponds to ones own 
file upon receiving an attach.reply» the 
attach was approved b the network 
controiter only. 


The field reflects the actual number of 


_LSNs that exist in the REMOTE_FILE. 


This number is used to determine the 
number of stations actually attached. 
Due to the PASS = sechanisms LSNs are 
never removed from a remote file» even 
?f a station is detached. Thus» while 
the MCS may attespt to attach 5 
Stations» only 3 new LSNs may be added 
to the remote file. Because of this» 
the fietd is used by the MCS to. set 
REMOTE_FILE_CURRENT_STATIONS>» which is 
set only upon receiving the 
ATTACH.REPLY. 


ATTACH REVIEW CRITERIA 


Sefore 


the network 


an attach is approved without being sent to another MCS> 


controtler verifies that: 


The remote file exists Cuser.remote.file.eno is valid) 


The attach tnitiator approved the open of the remote file 


or the attach 


Current.stations 


initiator 1s the user remcte file 


* the stations atready attached to the 


file is less than or equal to max.stations for that file 


The following conditions are true: 


1. 


and 2e 


and 3. 


and 4. 


and 5. 


the station exists 
the adapter is present 
the station is appropriates i.e.» that 


ae the 
b. the 
ce the 

the 


old 
old 
otd 
oid 


the nesting 


not too deep 


prieary is null 

primary is the attach initiator 
pri@ary does not have headers and 
secondary is the attach initiator 


of open approvals and attaches is 


if the file is indicated as participating» the 
is the attach initiator 


prigary 
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Before an attach is sent on to the controliing remote file (not 
the attach initiator) for approvals» the network controiter veri- 
fies that: 


A. The remote file exists Cuser.remote.file.eno is valid) 


Be. The attach tnitiator approved the open of the remote file 
or the attach initiator is the user remote file 


C. Current.stations t+ the stations already attached to the 
file is tess than or equal to sax.stations for that file 


D. The following conditions are true: 


1.. the station exists 
and 2. the adapter is present 
and 3. the station is appropriates i.e.» that 


| ae the old prisgary is null Cnot all stations) 

or b. the old prisary is the controlling remote file 

or ce the old primary does not have headers and the 
* atd secondary is the controlling remote file 


and 4. the nesting of cpen approvals and attaches is 
not too deep 


Before an attachereply is processed and approved for the attach 
initiators the network controtler verifies that: 


A. The remote file exists Cuser.eremote-file.no is vatid) 
8. The attach was forwarded to the CRF for approval 
C. The CRF set approve.deny to "1" indicating approval 


D. Current.stations # the stations already attached to the 
file is less than or equal to max.estations for that file 


E. The following conditions are true: 


1. the stations exist 
and 2. the adapter is present 
and 3. the station is appropriates i-e@e» that 


ae the old prigary jis null 

or be. the old priagary is the controlling remote file 
or Cc. the old priagary does not have headers and the 
old secondary is the controlling remote file 


and 4 the nesting of open approvals and attaches 
is not too deep 
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QETACH MESSAGE 3 7 4 


The detach is related to the close in the same way that attach is 
related to the open message. It is provided for negating the 
effect of an attach» removing stations from the station List of a 
remote file and returning them to their previous owners. 


If. the user.remote.file.no is valid» the detach with be proces~ 
sed» station by stations», according to the following criteria: 


1. <A file may detach a station from itself. If there is a 
file which approved the open of that file» it is notified 
via the detach message forwarded by the network 


controller. This indicates to the receiving file that it 
is) now the primary file again. 


2e A file aay detach a station from a file whose attach or 
open it approved. 


3. When a station its detached from the remote file speci- 
fied» it ts also detached from all files to which it had 
subsequently become attached. 


4. When an attachereply has an errors a detach message is 
‘sent to the CRF with the attach.ereply.in.error field set. 


This aliows for three different detach messages: 


1. Messages sent by a remote file with headers to detach a 
station from its file or a directly subordinate file. 
These detach sessages wilt be responded to with a 
detachereply from the network controller» the LSN List 
indicating stations actually detached. 


2- Messages sent by the network controller to notify an MCS 
that it now controts a tist of stations. No detach.reply 
is necessary. 


3. Messages sent by the network controller to notify a CRF 
writing an attach.reply that the attach.reply had an 
error and the attach did not get processed. No 
detach.reply is necessary. 
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DETACH AND CLEAR 
An CS may request that the LSN of a station being detached be 


removed from the FIB of the remate file. This actions which 
clears the LSN for the FIB*s station table, is catiled the CLEAR 
option. It perwits coamunication with any number of = stations 


(not toa exceed FIB.REAL.~MAX stations at any given tiae) instead 
of limiting comaunication to the first stations that sign on or 
pass input to 4a program. As a result of this options once a 
station is detached» messages cannot be written to that station. 


Some proegraas using the CLEAR option are subject to unexpected 
results. Progrags that do not contain ON EOF branches for their 
reaote file write statements ares upon atteapting to write, 
detached by the MCP with an tnvaiitd key message. Also» programs 
using relative keys may incur a situation where the message is 
sent to the wrong LSN. For example» if station A signs on to 
program X which employs relative keys in its remote file reads 
and writes» the MCS fires up pragram X and places station A*s LSN 
into the FIB. Consequently» whenever program X writes a response 
to RKSN tis» the traffic is sent to station A. A problem occurs 
when a particular input request requires lengthy processing time 
before crogram xX returns a response. If station A signs off 
prior ta receiving the responses that response could erroneously 
be directed to the wrong LSN.w~ When the MCS issues the DETACH and 
CLEAR» the LSN is removed from the FIB. If station B signs on to 
program X before the response is ready» it with receive the 


message intended for station A. If program X sends the response 
after station A signs off and before station 8 signs one an 
invalid key exception wilt occur. A simple detach wiil deliver 


the response to station A when the user signs on again. 


The following is the format of the detach message: 


Table 4.4 DETACH/DETACH.REPLY 


MCS<NC NC=-éCS 

H R H R PIC 
MESSAGE.TYPE + * * & 99 
USER.~REMOTE.FILE.NO + te * te 999 
ATTACH.REPLY.IN.ERROR * te 9 
CURRENT.STATIONS & t & & 999 
DETACH.AND.CLEAR & * * * 9 
FILLER XC5) 
LSN.LIST + & * _ (99938 


The semantics of the fields of the detach and detach.ereply 
messages are the sage as fields in the OPEN message with the 
exception: 
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ATTACH.REPLY .IN.ERROR A boolean wvhichs when set to “1"»s indi- 
cates that the attachereply was in 
error. 

DETACH. AND.~CLEAR A bootedn which indicates to the NC and 
MCP the need to reaove the LSN from the 
FIB. 


ELOSE MESSAGE 


The ctase message is provided as a negation to the open message. 
Close messages originate from the operating system and are passed 
to the resote file which approved the file open. Also» a close 
may be initiated by the network controller if an open.repty 
approving an ocpen was in error Csee OPEN). The close message 
requires no reply. 


If an MCS closes its files the files whose cpens it approved wiil 
also be closed. They will receive no new messages. An end-of- 
file wessage is queued after the last currently-queued message. 
The stations are relegated to the primary/secondary configuration 
which existed before the closed file was opened. The one excep=- 
tion tc the above rule is when an MCS participates in user 
program [/0» a close on the remote file does not aiter the 
primary and secondary files for the station. 


Following is the format for the close message: 


Table 4.5 CLOSE 


NC-HCS , 
| HOR PIC NG 

MESSAGE. TYPE + + 99 

CLOSE.TIME * 907) 

PROGRAM. JO8.NO + $(7) 
USER.REMOTE.FILE.NO + + 999 

OPEN.ERROR a & 9 

CURRENT.STATIONS + 4 999 

FILLER | X(6) 

LSN.LIST “  * (99994 


The semantics of the fields in the close message are similar to 
the open message with the exception: 


OPEN.ERROR A boolean set by the network controtler 
to indicate that an MCS open approval 
was invalid. 
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STATUS MESSAGE 


Status is now only appiicable to stations. The format of the 
station status/statusereply message is as follows: 


Table 4.6 STATION STATUS REQUEST/REPLY 


4CS<-NC NC-MCS 
W -R W R PIC 
MESSAGE.TYPE * * * 99 
LSN +... * & 999 
REQUESTING LSN S * 999 
STATUS .ERRGR - - * & 9 
STATION. NAME - - * * XC10) 
STATION.READY - - * * 9 
STATION. ENABLED - - * * 9 
STATION. MYUSE = = * & 9 
STATION. TERMINAL TYPE - - ie * 99 
STATION. BUFFERSIZE - - * * 9(5) 
STATION.TRAN.NO.SIZE = - * - 9 
STATION. TRAN.RECEIVE - - * * XXX 
STATION. TRAN.TRANSHIT = - fe ms XXX 
STATIGN.RECEIVE .ADOR.SIZE - - * * 99 
- STATION.~j TRANSMIT. ADOR.SIZE - - * * 99 
STATION. ADOR.RECEIVE - - * * X€20) 
STATION. ADDR.TRANSHIT - - & « X(20) 
STATION.MAX.RETRIES - - * & 999 
STATITON.PRIGRITY RECEIVE - - * * 999 
STATIGN.~PRIORITY.~TRANSMIT - - * rs 999 
MESSAGE.COUNT - - * « 9(4) 
DIAGNOSTIC.REQ.ON - - * t 9 
LOGICALACK.ON - - Pe Py 9 
GOGO.RESULTS.ON - - * te 9 
STATION. TALLIES - - * * 9(9) 
STATION. TOGGLES - - * * 9(8) 
STATION.REMOTE.FILE - - * i 999 
REMOTE.FILE.HAS.HEADERS - - i * 9 
STATION.PHONE - - * * XC20) 
STATION. VALID - - te * 9 
STATION.LINE.NO - - * * 99 
STATION. SECONDARY. FILE .NO - - te * 999 


FILLER 


LINE.COUNT = = * * 
LINE. INFO = = * * C999)2 
LINE #&# 99 

ACU 9 


It is noted that only message.type and LSN fields are required 
for a valid status message. 
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The semantics of the status message fields are as follows: 


LSN The logical station number of the 
station» the status of which is reques= 
ted/provided. 

REQUESTING. LSN Provided for designating the station 
requesting the information. It is not 


required to be valid. 


STATUS. .ERROR. Returned frowa the network controller and 
is "1" except when the LSN provided in 
the status request was invalids in which 
case it is *0". 


STATION.NAME Through diagnostic.req.on provides the 
Same information as the station status 
reply aessage of previous releases» but 

in character format. 


STATION. TALLIES Provides tallies 0-2 and toggles 0-7 in 
STATION.TOGGLES the same format as the data message. 


STATION. REMOTE.FILE Indicates the number of the remote file 
to which normal input ts attached. 


REMOTE.FILE.HAS.HEADERS Indicates whether the above remote file 
was opened by an MCS<-type program. 


STATION. PHONE The current phone number assigned to 
this station. Phone numbers are treated 
the same as with the NOL compiler. any 
invalid digit in the string is replaced 
by the pause character (FF hex). 


STATION.LINE NO The current tine assignment for _ the 
Station. ‘ 


STATION.SECONDARY.FILE.NG The remote file number of the station's 
secondary. If it ts "000%, then there 
is no secondary. 


LINE.COUNT The number of Lines on which the station 
is defined. 


LINE.~INFO Line.ecount 3-character fietds describing 
the Line number Cchar 2) and its asso-~ 
ciated diatout status boolean (char 1). 


A program with remote file headers may send a status @Bessage and 
receive a corresponding status reply. 
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CHANGE MESSAGE 


The only parameters subject to change are station change parame- 
terse Line attributes are opaque to an MC5. 


The format of the change and change.reply is as follows: 
As of &.0» an MCS may no Longer issue a CHANGE awessage affecting 


STATION ENABLED. This flag is used internally by the NC for 
queue tanagesent. 


Table 4.7 CHANGE/CHANGE .REPLY 


: MCS=-NC NC-MCS PIC 
MESSAGE.TYPE t * * * 99 
LSN + * * 999 
REQUESTING.LSN * * XXX 
CHANGE.TJYPE + * fe 99 
CHANGE.RESULT ; * * 9 
CHANGE .VALUE + te * X(20) or 
XXX or 
999 or 
X or 9 


(See chart below.) 


The semantics of the change message are as follows: 


LSN The station whose parameter is to be 
changed. 
REQUESTING.LSN An optional fietid provided for the LSN 


of the station directing the change. 
This field is not used by the network 
controller and can contain information 
in any foregvat desired. 


CHANGE.TYPE , Indicates the field to be changed. The 
meanings are: 


CHANGE TYPE FIELD VALUE FORMAT 
"00" TRANCRECEIVE ) XXX 
"01" TRANCTRANSMIT) XXX 
"02" ADDRESSCRECEIVE) X€20) 
"03" ADDRESSC TRANSMIT) x(€20) 
"04° FREQUENCY CRECEIVE) 999 
"05" FREQUENCYCTRANSMIT) 999 
"06" MAX RETRY 999 


"08" READY = 
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"09" | DIAGNOSTIC.ON 9 
"10" LOGICALACK.ON 9 do- 
"117 GOODRESULTS.ON 9 
"12" STATION.PHONE X¥€20) yr? bw 
"13" SIGNAL .CHARACTER X Noh 
ot ——— 
CHANGE .RESULT Returns "1% unless there was an error in 
the message. "O" gaplies an invalid. 
LSN. “2° implies an invalid nge 
type. 


CHANGE .VALUE The field's new value in Left-justified 
character format. 


RECALL NESSAGE 


REMOVE MESSAGE 


The recail message is provided for removing any number of 
messages from the top of a station's output queues marking thea 
as recadledemessageS» and sending them» prefixed by a 
recait.reply message» to the MCS. The recall.ereply contains the 
number of messages to follow. 


The remcve message is provided for removing any number of 
messages from the top of a station’s queue. The network 
controdiler will always respond with a remove.reply indicating the 
number of messages actuality removed. 


A cautionary note: when using recail and remover» it is best to 
make the station not ready first as otherwise the first message 
may or may not be included» depending on whether the station is 
currently being processed. 


Recall» recail.reply>» remove and remove.reply messages are 
forgatted as fotlows: 


Table 4.8 RECALL/RECALL.REPLY 


MCS=NC NC -MCS 
R W PIC 
MESSAGE.TYPE + * * i 99 
LSN + * i 999 
REQUESTING.LSN w * 999 
MESSAGE .COUNT * . wt * te 9(4) 
RECALL.~ERROR ke 9 
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The semantics of the RECALL format are as fotlows: 


LSN The station from whose output queue the 
messages are to be recailed or removed. 


REQUESTING.LSN This field indicates the station initi- 


ating the recalt or prises Po 
7 
MESSAGE COUNT Originally the nuaber of messages tg—be 7 
| | recatled/ removed (€"001" for one> ? 
for ali) and in the reply» the numb Of : 
messages actually recailed/removed. 


RECALL.ERROR Set to "1" if the sessage is improperly 
formulated. 


A recall wiil place the recalled.messages immediately following 
the recall.repiy. 


REMOTE sFILESINEO MESSAGE 


An MCS-type program may controt a set of stations by opening a 


remote file with the header option. In order to provide neces 
sary inforaation about the file just acquired» the 
remote.file.info/remote.file.info.reply protocol is provided. 


The format is as follows: 


Table 4.10 REMOTE.FILE.INFO/REPLY 


MESSAGE.TYPE + * * A 99 L¢ ly 
JO8.NO t * 9(7) | 
TIME * * 9C7) 
REMOTE.FILE.NO #(*) * * 999 
CUTPUT.MESSAGES. QUEUED * * 9(4) 
INPUT.ME SSAGES.QUEUED * * 9€4) 
CURRENT. STATIONS * * 999 

OTHER.RF .REQUEST * & 9 

OTHER.RF ERROR * * 9 

OPEN. APPROVER.RF .NO & * 994 br 
Pie simple a | 30\ 
LSN.LIST * « C9990" 
OUTPUT. QUEVED.LIST | * * (999)¢ 


€*#) Mandatory only if GTHER-RF.REQUEST is “1”. 


It is noted that only message.type is required for a yalid 
remote.fileeinfo inquiry on the file originating the inquiry. 
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The semantics of the remaining fields are as follows: 


JO8.NO Job-nurmber of the MCS<-type fiie. 

TIME The time that the reply was sent. 

REMOTE.FILE.NO The number of your remote fite if 
other .rf.request is “0. It is the 


nuaber of the target remote (file if 
other .rf.request is "1". 


OUTPUT. MESSAGES. QUEUED The total of alt messages queued for 
output to all stations in the file. 


INPUT.MESSAGES .QUEUED The total of atl messages queued fron 
ali stations that are destined toa be 
read by your file. 


CURRENT.STATIONS The number of stations attached to the 


file. 
OTHER.RF .REQUEST "0" if the request is for the writing 


MCS*s file. It ts "1" if remote.file.no 
contains the file number about which 
information is requested. 


_ OTHER.RF. ERROR "1" in the reply is the requestor had 
set oaOther.rf.request to "1" and the 
remoteefileeno supplied was non~exis= 


tent. 

OPEN.APPROVER.RFE NO The rerwote file number of the MCS’ which 
approved the requestor"’s open. 

LSNeLIST Has an LSN for every current station. 

OUTPUT.QUEUED.LIST Has the output messages for each of the 
current stations. It should total to 


output.messages.jqueued. 


LINE RELEASE MESSAGE 


The LINE.RELEASE message allows a user to requests» through an 
MCS» that a tine (designated by a ports» channel» and adapter 
triplet) be released from ownership by the network controller. 
For instance» when a network controiler initiatizes a multiline, 
ail fifteen adapters are tested for the existance of an Autocrcall 
unit CACU). Since the MCP associates I/0 ops with the program 
issuing them» the network controller is considered the “owner” of 
ali fifteen adapters. The user may decide to use ane of these 
adapters for another programs, such as RJE» HASP» or a second 
network controller. In order for the MCP to atlow this» the 
lines that are not active aust first be released from ownership 
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of the first network controller via the LINE.RELEASE message. 


A line is released when the following conditions are met. 


le The NC owns the Line 


2e The dine status 


ae idle or na 
the Line. 


is 


messages are queued for a station on 


be. and no station on the Line is enabled 


5 If a multiline 


exists and the request is for a line 


with an ACU Cthe status of the ACU must not be "in- 


use"). 


The forwat for LINE.RELEASE and LINE.RELEASE.REPLY is: 


Table 4.9 LINE.RELEASE/LINE.RELEASE.REPLY MESSAGE FORMAT 


NC-4CS MCS=<NC 
R W R PIC 
MESSAGE.TYPE * * + * 99 
REL.PORT.NUMBER * + * 9 
REL.CHANNEL.NUMBER * + ae 99 
REL.ADAPTER.NUMBER * + * 99 
RELRESULT t & x 


The semantics involved in 
MESSAGE.TYPE 
REL~PORT.~NUMBER 
REL CHANNEL .NUMBER 
‘REL. ADAPTER.NUMBER 


REL .RE SULT 


the message format are: 


"30" - LINE.RELEASE 
"31" - LINEJRELEASE.REPLY 


The triplet that describes the line to 
be released. 


“O" - Line released 

"1" += not released» NC not owner of line 
"2" - invalid parameters 

"3" = not releaed» NC using Line 
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CONTROL MESSAGES 


Additional control messages have been made available to implement 
ANSI COBOL74 within the 81000 datacomm framework. These messages 
only pertain to an MCS interacting within a COBOL74 environsent. 
Further reference should be made to the facilities described in 
the Cossgunications Module section of the COBOL74 product speci- 
fications P.S. #### #BOH. 


Tables 5.1 and 5.2 tist the messages and their types. 


Table 5.1 MESSAGES READ 


MESSAGE TYPE 


C74.CLOSE . 16 
C74.0PEN 18 
C74. CREATE.QUEUE . 34 
C74.ENABLE.OISABLE 36 
C74. 0ELETE.QUEUE 38 


Table 5.2 MESSAGES WRITTEN 


MESSAGE TYPE 
C74.0PEN.REPLY | 19 
C74.CREATE.QUEVE REPLY 35 
C74. ENABLE.OISABLE REPLY 37 
C74.DELETE.QUEUE.REPLY 39 
Cf4 CLOSE 


then a COBOL74 program goes to EQJ»> the MCP wit generate a 
normal CLOSE sessage to the network controlter for each input 
queue associated with the prograg. If there is an MCS that 
approved the open of this input queue then the network controller 
will pass the CLOSE message to the MCS involved for informaticnal 
purpose only. 


If the MCS did not create the input queue and this COBOL74 
program is the Last job associated with the input queue» the MCP 
witl remove the queue. However» if the MCS created the queue 
criginaily» then the MCP wilt not remove it. In the latter case, 
the MCS is expected to eventuatily issue a C74.DELETE.QUEUE 
request to remove the queue. 
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Table 5.3 Lists the forgat for the CLOSE message. 


Table 5.3 C74 CLOSE FORMAT 


NC-mCS 

c R PIC 
MESSAGE.TYPE & - * 99 
CLOSE.TIME = * 9(7) 
PROGRAN. JOB.NO * * 9(7) 
USER QUEUE .NOD * te 999 
OPEN.~ERROR * * 9 
CURRENT.STATIONS * * 999 
COSOL74.FINAL * 9 
FILLER XC(5) 
LSN.LIST * * C999)2 


The semantics of the fields in a C74.CLOSE are the same as a 
normgat close except that COBOL74.FINAL is set to 1 by the MCP if 
the CLOSE applied to the Last COBOL74 job using USER.QUEUE.NO, 
and if USER.QUEUE.NO wasn't created by the MCS. 


C74 QEEN 


The MCP issues a C74.0PEN message to the network controlier when 
a COBOL74 program executes either a RECEIVE statement or an 
ENABLE INPUT statement for a queue that does not exist» oor for a 
queue that exists but with which the program has not been asso- 
ciated. 


Association of the program with the queue takes place iaplicitly 
upon the first ENABLE INPUT or RECEIVE statement. ODisassociation 
occurs when the program goes to EQJ. 


The network coantroller treats this message as an OPEN request. 
If there is an MCS involved» the network controller will forward 
the message to the MCS for appraval. The network controller then 
expects an C74.CPEN.REPLY message from the MCS» andthe network 
controller will relay this C74.0PEN.REPLY message to the MCP via 
a DC_WRITE communicate. If the open request is approved» the MCP 
wiil build a FI8 for the queue at this point if one does not 
exist already. 


® 
Upon reinstatement», the COBOL74 program examines the status key 
in its input CD to determine the outcome. 


PasswORes 


COBOL74 data communications makes provisions for the use of pass- 
‘wordse IHIf the boolean PASSWORD.USED is sets» the MCS verifies the 
validity of the field PASSWORD» and if the field is invatid, 
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C74.0PEN is denied. If the baolean is not set» no action is 


required of the MCS concerning passwords. 


SIMPLEHEADERS 


The NE allows a CVY4.0PEN only if SIMPLE.HEADER.OPTION and 
HEADER.OPTION are set and if REMOTE.KEY is not set. 


PABTICI£ATING 


COBOL74 data communications input queue opens aay be approved as 
"participating™ by an MCS. In this case» data input fron 


Stations to these queues wiil be routed (by the network control- 
ler) to the MCS that approved the open. Oata output by a COBCL74 
SEND to stations will be routed Cby the SMCP) to the MCS that 
approved any open for the COSOL74 program. Thus» participation 
on output messages wilt happen only after a queue open is 
approved by the &#CS. Participation on output messages is on a 
program. basis rather than on a queue (file) basis because SENDs 
refer oanty to a station (Cterminal or SYMBOLIC DESTINATION), 
rather than to a queue or file. Thus» if any input queue open 
for a CQBOL?74 prograse (such as one of many) is approved as 
participating» ail SEND output by that program witl be sent to 
the MCS that first approved the open as “participating™» instead 
of being sent directly to the -station. 


Note that in order for the sending of partial messages or the 
sending of message segments to work correctly» according to 
COBOL74& ANSI standards» it is imperative that the MCS involved be 
a participating MCS. The MCS is expected to tank partial 
messages or seggents before sending a full message to a station. 
The 81000 MCP does not do the tanking. 


Tabie 5.4 tists the format for the COBOL74 open and its reply. 
Following the tadle is a list of fields that differ from a normal 
remote file cpen. 
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Table 5.4 C74.OPEN/C74.0PEN.REPLY FORMATS 


MESSAGE. TYPE 
OPEN.TYPE 
OPEN.TIME 
PARENT.JOB.NO 
PROGRAM. JOB.NO 
PROGRAM.~NAME 
HEADER. CPTION 


SIMPLE.HEADER.~OPTION 


REMOTE.KEY 
RESIDENT 

USER .QUEUVE.NO 
SIGNAL .CHAR 
APPROV.DENY 
DENY.REASON 
PARTICIPATING 
GOOD.RESULTS 
MAX.STATIONS 
CURRENT.STATIONS 
LIST.TYPE 
FILENAME 
PROTGCOL.TYPE 
SESSION e 
PASSWORD 
PASSWORD .USED 
INPUT.Q.RECORD.SIZE 
INPUT.Q.BUF FERS 
INPUT.Q.DEPTH 
ESI 

EGI 

EMI 

FILLER 
STATION.LIST 


MESSAGE.TYPE 


PROGGRAM.JOU.NO and 
PROGRAM.NAME 


APPROVE.DENY 


DENTAL.REASON 


» * * » » © HF pe ee 


NC MCS 
R 


MCS<NC 
W R 
+ * 99 


** ee 
-o) 
a) 
~j 
ww 


% se > & 

+ ses *¢ ee ee 
ve} 

© 

oo 


> eeeyp h 2 H & & eH 
wo 
“~~ 
F 


+t ee 8 
»* ee * 
Ne] 
ro 
> 
bad 


XC7) 
C999) # 


C74.0PEN = "18%, C74.0PEN.REPLY = "197 


Will always contain the values 
associated with the COBOL74 program 
originating the run unit. Thus» if the 


program for which this C74.0PEN has been 
issued was "CALLED"» its job number and 
name wili not be given. 


Set in the C74.0PEN.REPLY. 
S17 


bell ¢ Had 


if approved. 
if request is denied. 


Te 


Valid only if APPROVE.DENY = 


> ia | 
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by MCS = = "1" if invalid @ key. = "2" 
if invalid password. 

PASSWORD 1) If an “ENABLE INPUT <queue=nage>” 

PASSWORD.USED caused C74.0PEN to be generated» 
PASSWORD is required and PASSWORD.USED = 
ba lees 


23 If a “*RECEIVE™* <queuesname> statenent 
was executed by a COBOL74 program»s the 
C74.0PEN generated by the MCP will 
have PASSWORD set ta att blanks and 
PASSWORD.USED will equal “0”. 


INPUT .Q.RECORD.SIZE Default value Cequals maxinus buffer 
size for any terminal on the line) is 
set by the NC. The MCS can alter the 
value in the reply. 


INPUT.Q.8UFFERS Default (2 buffers) is set by the NC 
before it forwards message to MCS. The 
later can alter the value in the raply. 


INPUT.Q./DEPTH Set by NC and atlterable by the MCS. 
Defauit is 10. 


CLS CREATE A QUEVE 
This messager» issued only by an MCS» causes the explicit creation 
of a COBOL queue. There are two intended uses for this messages 


one is for applications employing transaction-based routing 
CTBR)J» and the other is for situations in which the MCS is aware 
of the future requireaents for a specific queue or set of queues 
and can create them before they are actuaily needed. The reply 
from the NC indicates the renote file nusber of the queue just 
created. When the MCS schedules a COBOL74 job that wilt use a 
previously created queues the syntax for symbolic queue name 
(SQN) is used. 


An isportant difference exists hetween the C74.0PEN and the 
C74.CREATE.QUEUE requests. The creation of a queue via a 
C74.CREATE.QUEUE request does not give a COQB8OL74& program auto- 
matic access to it. Moreover» a queue created explicitly by an 
MCS is not removed because there are no COBOQL74 programs using it 
for data transfer. The queue is not closed until either the MCS 
goes to E0J» or until the MCS issues an explicit close. However> 
the queues built as a result of a C74.0PEN request» are destroyed 
when the last program having access to it goes to EQJ. 


The MCS is considerably flexible in managing queues. If » for 
exaaple, the MCS receives an OPEN request that was generated in 
response to a C74.0PEN for a currently nonexistent queue» it has 
two possible options Cpending approval of the OPEN): one option. 
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is to issue the OPEN_REPLY and cause the creation of the queue 
which wilt grant access to the queue» or alternatively» the MCS 
can issue a C74.CREATE.QUEUE. wait for the C74. CREATE .QUEVE.RE- 
PLY» and return the OPEN_REPLY,» thus retaining control over the 
queue. In the Latter case» it is important that the MCS sets the 
USER.QUEUE.NG field in the C74&4.CREATE.QUEUE format to the same 
vaiue of the USER.QUEUE.NO field in the C74.0PEN format. 


The format for the C74.CREATE.QUEVE and C74.CREATE.QUEUE.REPLY is 
the same as the C74.0PEN except for the following fields. | 


MESSAGE. TYPE C74.CREATE.-QUEVE = 734" 
C74.CREATE.QUEUE.REPLY = “35" 
INPUT. Q.RECORD.SIZE If not set initially (that is» ="000*) 
' by the MCS» the NC defaults the value to 
"2000". 
INPUT.Q.BUFFERS Same default as for C74. 
USER. QUEUE.NO Must be set to "000" if not created as a 


result of an open request. 


L4oeENABLE DISABLE 


COBOL74 programs execute ENABLE/DISABLE statements to modify the 
logicat connectivity tetween sources and destinations and the 


associated queues. There are two possible input formats and one 
output format. For input» either the TERMINAL or INPUT 
<queue-id> form is used. With the TERMINAL form, message 


transfer from that station is allowed or disallowed accordingly. 
With INPUT <queuecid>» the connection path is established/broken 
and an OPEN/CLOSE is appropriately issued by the MCP to the NC. 
For outputs only the TERMINAL forms is used. 


ENABLE/OISASLE requests are forwarded to the NC by the MCP. If 
an MCS is present» the NC passes the request and waits for a 
reply. Requests of this type may not be generated by the MCS. 
If the request is logically valid and an MCS is not involved» it 
witt be granted. To be Logically valid» the STATION.NAME must 
exist within the datacomm networks and the station must already 
be attached to a COBOL74& queue. 


The password option is an  addittionat interaction that occurs 
between the ENASBLE/DISABLE requests and the MCS. The administra- 
tion of this option is the responsibility of the MCS. Within the 
message is a 10-byte field which contains a character string. 


Table 5.5 Lists the format of the C74.ENABLE.DISABLE request and 
is followed by a description of the various fields. 


Table 5.5 C74 ENABLE .CISABLE/C74.ENABLE~OLTSABLE.REPLY FORMATS | 


SURRQUGHS CORPORATION 
COMPUTER SYSTEMS GROUP 
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MESSAGE.TYPE * * + * 99 

STATIGN.~LSN te & * 999 

STATION.NAME * t * X(€12) 

APPROVE .DENY * fe + te 9 

DENIAL.REASON + * 9 

FILLER 9 

PASSWORO * * X(€10) 

PROGRAM. J0B.NO * * te 9(7) 

ENABLE .DISABLE * * & 9 

USE * * * 9 

USER -.QUEUE.ND ne * 999 

USER-QUEUVUE.~NAME * * * X(48) 

The geanings of the various fields are: 

MESSAGE.TYPE C74.ENABLE.DISABLE = "36" , 
C74 ENABLE .DISABLE.REPLY = "37" 

STATION.LSN Valid only if USE = "0" or USE = "1". 
If not equal to *000", then the LSN of 
station affected. 

STATION. NAME Valid only if USE = "0" or USE = 1". 
Identifier uniquely representing this 
Station within the network controller. 

APPROVE.DENY = "1" if request is approved. 
= "0" if request is denied. 

DENIAL.~REASON Valid only if APPROVE.DENY = "0". 
= "1" $f invalid queue CUSE = "2") or 

if invalid station CUSE = "0" or “"1"). 
= "2" if invalid password. 

PASSWORD Character string sent from program to 
MCS via MCP and NC to be used for pass- 
word validation. 

PROGRAM.J0O8.NO The job number of the COBOL74 program 
which originated the run unit Cnot 
necessarily that issuing the request). 

ENABLE.DISABLE = "1" jf an ENABLE request. 
= "0" if a DISABLE request. 

USE 1/0 mode: 
= "0" if OUTPUT. 
= "1" Ff INPUT TERMINAL. 
= "2" if INPUT <queue id>. 

Valid only if USE = "2". The user queue 


USER .QUEVE .NO 
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~ 


number associated with USER.QUEUE .NAME. 


USER.QUEUENAME Valid only if USE = "2". Name of the 
. queue. 


C74 DELETE QUEVE 


The C74 Delete Queue is used to remove a queue that was created 
via a C74.CREATE.QUEUE. Only an MCS may issue such a request. 
The format is described in Table 5.56. 


Table 5.6 C74.D0ELETE.QUEVUE.FORMAT 


MCS=NC 


Hi R PIC 
MESSAGE.TYPE + * 99 
USER.QUEUE.NO + * 999 
MESSAGE.TYPE = “38" 


L@4 QELETE QUEYE REPLY 
The C74 Delete Queue Recly that is returned to the MCS from the 
as 


NC h the same format as a C74.CLOSE with the following sean- 
ings: 
MESSAGE.TYPE . = "39" | 
PROGRAM.J0C8.NO Set to the job nusber of the COSOL74 
program originating the run unite 
USER .QUEUE.NO Same as USER.REMOTE.FILE.NO in a normal 
CLOSE sessage. 
OPEN.ERROR Set by NC to indicate action taken in 
response to request: 
= "1" if no errors? queue removed. 
= "0" if USER.QUEVE.NO stili in uses it wilt 
be removed when released. Please noterp 
however» that the MCS no Longer has 
any control over the queue. 
= "2" if USER.QUEUE.NO was invalid. 
= "3" if the USER.QUEVUE.NO specified in the 
request does not betong to the MCS. 
COBOL74.FINAL | Set by the NC to indicate whether there 


are any amore COBOL74 programs using 
USER.QUEUE .NO. 
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= "1" if no more programs. 


DATA MESSAGES 


To facilitate COB0L74» =a new data message tyne has been created» 
in addition to the normal message. 


TYPE = 708" 


This ts a regular data message except for the message type which 
equals 708". An MCS which owns stattons accessed Cor to be 
accessed) by COB8OL74 programs should be prepared to accept this 
message type. Such a message will be received infrequently since 
a precondition for its generator is an attempted SEND to a 
Station Cowned by this MCS) from which no COBOL74 program has yet 
done a RECEIVE. In this situation» the MCP does not know whether 
or not access to this station has previously been granted? ther- 
efores, the sessage will be forwarded to the MCS who either sends 
it on toa the station or discards it. Howevers the status key 
field» when returned» always indicates that the message was sent 
to the station and there is no repiy expected from the MCS. 
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MCP ACTIONS UPON A COBOLZ4 RECEIVE OR ENABLE/OISABLE INPUT 


The fotlowing describes actions the MCP takes when a COBOL74 
program does a RECEIVE from an input queue or an ENABLE/DISABLE 
INPUT <queue id>. 


RECEIVE from an input queue: 


- If the queue does not exists the MCP will first send a 
C74.0PEN message to the network controller. 


- If the queue exists and the progras is associated with 
the queue» then the MCP wilt send the message if the 
queue is enabled? or 


- If the queue exists and the prograa is not associated 
with the queues then the MCP wiil first send a C74.0PEN 
pessage to the network controller. 


ENABLE INPUT <queue id>: 


- If the queue does not exist» the MCP will send a C74.0PEN 
~~ gessage to the network controlter. 


- If the queue exists and the prograa is associated with 
the queue» then the MCP will send a C74.ENABLE.INPUT 
<queue id> message to the network controllers or 


- If the queue exists and the prograsg is not associated with 


the MCP will send a C74.0PEN message to the network 
controller. 


* 


DISABLE INPUT <queue id>: 


- If the queue does not exist» then the request is not honored 


with INVALID.Q.KEY as the reason. 


- If the queue exists and the programs is associated with 
the queues» then the MCP witl send a C74.DISABLE.INPUT 
<queue id> message to the network controiters or 


- If the queue exists and the progras is not associated 
with the queues then the request is not honored with 
IINVALID.Q@.KEY as the reason. 
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Note that 


1. Associatior of the COB8OL74 program with an input queue 
is established upon the RECEIVE statement or upon the 
first ENABLE INPUT <queue id>. 


2. Diassociatior of the COBOL74 program with an input queue 
does not occur upon a OISABLE INPUT <queue id>. Rather» 
if occurs when the program goes to EQJ. 
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USER HESSAGES 


An executing MCS may interface with a user remote file without 
headers through the following record format: 


Yable 6.1 USER-DEFINED MESSAGE 


NC-MCS MCS-NC MCS-USER USER<-NCS FIELD LENGTH 

i R W R Ww R W R PIc 
MESSAGE.TYPE us * + te + C«) €«) * 99 
VARIANT i & * * * -_ - 9 
LSN a te * * & €«) C«) t 999 
TEXT.SIZE * i + te + (*) {*) * 9(€4) 
REMOTE.FILE.NO * « & ry + - - 999 
TIME * a - - 9C7) 
TRAN .NO * * - ~ 999 
ERROR * * - - XX 
TALLYS * * * * ~ - 9(€9) 
TOGGLES oI * * * - - 9(8) 
TERMINAL.TYPE * * - - 99 
FILLER X(6) 


TEXT * * * * * * * * XCTEXT.SIZE)D 


The semantics of the fields of the USER-DEFINED message record 
are: 


MESSAGE.TYPE Established by the user program and must 
be a number greater than 49 and less 
than 100. 
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ATTACH MESSAGE 4-11 

ATTACH REWIEW CRITERIA 4-15 
ATTACH TABLE 4-12 

ATTACH.CNT 4-15 

ATTACH.REPLY .IN.JERROR 4-18 
ATTACHING.REMOTE .FILE.NO 4-14 


BASIC TERMINGLOGY 1-3 


CHANGE MESSAGE 4-22 

CHANGE .RESULT 4-23 

CHANGE .FYPE &~22 
CHANGE.VALUE 4-23 

CLOSE MESSAGE 4-19 

COBOL74& MESSAGES a=1 
COBOL74. FINAL 3°78 

CONTROL MESSAGES &= 15 3-1 
CURRENT. STATIONS 4-6~» 4°25 
C74 CLOSE 3@1 

C74 DELETE QUEUE 53-8 

C74 DELETE QUEVE REPLY 3=8 
C74 OPEN Rat 

C74. CREATE.QUEUE 222 
C74,ENABLE.DISABLE 5-6 


DATA MESSAGES 3rie 5°§ 
DENTAL.REASON &-bs 4-145 5-49 5-7 
DETACH AND CLEAR 4-18 

DETACH MESSAGE 4-17 

DETACH. AND.CLEAR 4~-19 

DUMMY REMOTE OPEN 4-3 


ENABLE.ODISABLE 5-7 
END_KEY 3-4 

ERROR 3-3 
FILE.NAME = 4-7 


GENERAL OESCRIPTION isZ 
GOOO.RESULTS 4-6 


HEADER.OPTION aah 
INPUT. MESSAGES.QUEUED 4-25 
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INPUT .Q-RECOROD.SIZE 5°53» 5°6 
JOB.NO 4-25 
KEY TO ASBREVIATION erZ 


LINE RELEASE MESSAGE 4=25 
LINE.COUNT 4-21 

LINE .INFO 4-21 

LIST.TYPE 4-7 

LSN 3-35 4°212 4-22» 4°24 
LSN.LIST 4-25 


MAX.~STATIONS 4-6 

MCP ACTIONS UPON A EuscEsS. RECEIVE OR ENABLE/OISABLE INPUT 
MESSAGE TYPES 271 

MESSAGE.COUNT 4-24 

MESSAGE.~TYPE 6-1 


OPEN MESSAGE 4-1 

OPEN REPLY 4-1 

OPEN REVIEW CRITERIA 4-8 
OPEN WITH HEADERS 4-2 

OPEN WITH SIMPLE HEADERS 4-3 
OPEN.APPROVER.RF.NO 894-25 
OPEN-ERROR 4-19» 5-8 
OPEN.TIME 4-4 

OPENTYPE 4-4 
OPEN/OPEN.REPLY FORMAT 4-3 
OTHER.RF.ERROR 4-25 
OTHER.RF REQUEST 4-25 
OUTPUT.MESSAGES.QUEUED 4-25 
GUTPUT.QUEVED.LIST 4-25 


PARTICIPATING 4-6» 5-3 

PASSWORD 5-55 5-7 

PASSWORD.USED i at 

PASSWORDS © ad 

PROGRAM. JCB.NO 8-4, holds S49 S-7» 5-8 
PROGRAM.NAME 8-4, 5-4 

PROTOCOL.TYPE 4-7 


RECALL MESSAGE 4-23 

RECALL .ERROR 4-24 
RELATED OOCUMENTATION 1°5 
REMAINDER.SON 574 

REMOTE FILES imi 

REMOTE.FILE HAS.HEADERS 4-21 
REMOTEFILE.INFO MESSAGE 4-24 
REMOTE.FILE.NO 3-35 4°25 
REMOVE MESSAGE 4-23 
REQUESTING.LSN 4-215 4-220 4°24 
RESICENT 4-5 


IX=2 
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RESQURCE SHARING 172 


SESSION 4°7 
SIGNAL-CHAR 4=S5> 4-14 
SIMPLE.HEADER.OPTION 4-5 
SIMPLE.HEADERS 5-3 
STATION.LINE.NO 4-21 
STATION.LIST 4-7 © 
STATION-LSN 5-7 

STATION.NAME «4-215 5-7 

STATION PHONE  4=21 
STATION.REMOTE.FILE 4~21 
STATION.SECONDARYoFILENO 4-21 
STATION.TALLIES 4-21 
STATION.TOGGLES 4-21 

STATUS MESSAGE 4-20 
STATUS.ERROR 4-21 


TALLY 3°4 
TERMINAL.TYPE 3~4 
TEXT J4 


TEXT.SIZE 3-3 
TIME 3-35 4°25 
TOGGLE 3-4 
TRAN.NO =. 3*3 


USE 3°7 

USE.REMOTE .KEY 4°5 

USER MESSAGES 6-1 

USER -QUEUE.NO 5-8 

USER REMOTE .FILE .NO 4-5 


VARIANT a3 


